1. Technical Field
The invention disclosed broadly relates to improvements in digital computer architecture and more particularly relates to an improved system and method for sharing a hardware interrupt among a plurality of input/output devices in a microcomputer system.
2. Background Art
Modern microcomputer systems generally include a central processing unit (CPU) which is connected by means of an address bus and a data bus to a plurality of input/output (I/O) devices such as serial communications devices, local area network interfaces, parallel printers, diskette controllers, real time clocks, specialized attached processors, fixed disk controllers and the like. Generally such I/O devices operate asynchronously from the CPU and only require the attention of the CPU at randomly occurring intervals.
Two principal approaches have been employed in the prior art to coordinate the servicing of such I/O devices by a CPU, the first approach being the status polling method and the second approach being the interrupt method.
FIG. 1 illustrates a generalized microcomputer system architecture employing the status polling method for servicing a plurality of I/O devices. FIG. 1 shows the CPU 20' being connected by means of the data bus 26 to a plurality of I/O devices 23 and 25 and to the system writeable random access memory (RAM) 32 and the system read only memory (ROM) 30. A plurality of status polling lines 21 are output from the CPU 20' and respectively go to each of the I/O devices 23 and 25. A multiplexer 19 can be used to reduce the number of polling lines 21 connected to the CPU. In the status polling method, the CPU 20' must test each I/O device in sequence and determine if it needs servicing. Since the main program in the CPU 20' devotes a substantial proportion of its time to periodically polling the I/O devices 23 and 25, this method has the effect of diminishing the system throughput for the microcomputer system.
FIG. 2 shows the alternate prior art approach employing the interrupt method. In FIG. 2, the CPU 20 is connected by means of the data bus 26 to the I/O devices 27 and 29 and to the RAM 32 and the ROM 30. An additional hardware element included in the system of FIG. 2 is the programmable interrupt controller (PIC) 22 which is also connected to the data bus 26. Each of the I/O devices 27 and 29 has a separate, dedicated interrupt line 28 going to the programmable interrupt controller 22. The programmable interrupt controller 22 receives an interrupt signal (IRQ) from one of the I/O devices 27 or 29 over that one of the interrupt lines 28 dedicated to that I/O device and the PIC 22 outputs an interrupt request (IREQ) to the CPU 20. The CPU is allowed to execute its main program until it receives an interrupt request (IREQ) from the PIC 22. It then stops to service that I/O device issuing the corresponding interrupt signal (IRQ). The interrupt request (IREQ) sent by PIC 22 to the CPU 20 informs the CPU that it should complete whatever instruction that is currently being executed and then fetch a new routine, called an interrupt handler, which will service the I/O device requesting the interrupt. Once this servicing is complete, the CPU 20 will resume its main program from the point where it left off. The interrupt method of FIG. 2 significantly increases system throughput over the status polling method of FIG. 1.
Programmable interrupt controllers 22 are available in the prior art which provide overall management in an interrupt driven microcomputer system. The programmable interrupt controller functions to accept interrupt signals (IRQ) from I/O devices, determine which of the incoming IRQ signals has the highest priority, determine whether the incoming IRQ signal has a higher priority value than the level currently being serviced, and issue an interrupt request IREQ to the CPU 20 based upon this determination. One example of such a programmable interrupt controller 22 is the Intel 8259A Programmable Interrupt Controller which is described in the iAPX 86, 88 Users Manual, August 1981, pages B-67 through B-83, published by Intel Corporation.
An example of a microcomputer system architecture employing a programmable interrupt controller 22 in the manner illustrated in FIG. 2, is the IBM Personal Computer which is described in the IBM Personal Computer Technical Reference Manual, August 1981, published by International Business Machines Corporation. This publication describes a central processing unit 20, embodied as an Intel 8088 CPU, which is capable of servicing eight interrupt lines 28 by means of a programmable interrupt controller 22, embodied as an Intel 8259A.
Each I/O device in FIG. 2 generally has a dedicated program which is associated with its specific operational requirements, generally called a service routine or interrupt handler. In the IBM Personal Computer, access is gained to the interrupt handler by means of an interrupt vector. The term "interrupt vector" means a location in memory which is used to hold the address of another location where the interrupt handler program is located. Initially, when system power is turned on, one of the initialization operations is to construct a set of at least eight interrupt vectors in the low order memory locations in the RAM 32. Each interrupt vector represents the memory address for the starting point of an interrupt handler routine for handling the interrupt signal from one of the eight I/O devices requesting an interrupt on a corresponding one of the eight interrupt lines 28. In the prior art mode of operation of the IBM Personal Computer, the Intel 8259A Programmable Interrupt Controller 22 detects an interrupt signal (IRQ0 through IRQ7) when an I/O device 27 or 29 pulls the corresponding one of the interrupt lines 28 to a relatively high potential. If the PIC 22 honors the request, the IREQ output line to the Intel 8088 CPU 20, will go high, indicating to the CPU that a valid interrupt request has been made. When an interrupt request is present at the IREQ line at the CPU 20, the Intel 8088 CPU 20 enters its interrupt acknowledge machine cycle. The interrupt acknowledge machine cycle completes the processing of the current instruction and stores away current status flags, the contents of certain operating registers, and the current instruction pointer onto a last-in/first-out stack provided in the RAM 32. The Intel 8088 CPU 20 then issues the first of two interrupt acknowledge (IACK) pulses which signal the PIC 22 that the CPU 20 has honored its interrupt request. The Intel 8259A Programmable Interrupt Controller 22 is now ready to initiate the execution of the interrupt handler routine by means of one of the interrupt vectors in the RAM 32. This is done during the sequence of the two interrupt acknowledge pulses (IACK) issued by the CPU 20. The second interrupt acknowledge pulse causes the PIC 22 to place a single interrupt vector byte onto the data bus 26, which pertains to the desired interrupt vector corresponding to the interrupt handler routine. When the CPU 20 receives the interrupt vector byte from the PIC 22, it computes the actual address of the interrupt vector location in the RAM 32. The contents of the addressed interrupt vector in the RAM 32 is then accessed by the CPU 20, that contents being the address of the beginning of the interrupt handler routine which will service the interrupt of the I/O device requesting attention. Program execution of the interrupt handler routine is then carried out by the CPU 20.
An example of the prior art mode of operation to perform a request for service can be given with an asynchronous communications controller as the I/O device 27, which has just received a byte of data from a communications medium. The I/O device 27 will request service from the CPU 20 to transfer the received byte of data to an appropriate buffer previously set aside in the RAM 32. The corresponding interrupt handler routine in the RAM 32 is accessed by its corresponding interrupt vector, and provides the instruction sequence necessary to enable the CPU 20 to perform the transfer of the received byte of data from the I/O device 27 to the RAM 32.
Once the interrupt handler routine has completed execution, the main program which was previously being executed by the CPU 20, may be reentered by using an interrupt return instruction (IRET) at the end of the interrupt handler routine. The interrupt return instruction (IRET) will read back the instruction pointer, code segments, and flags from the memory stack in the RAM 32 and will place them in the appropriate locations in the CPU 20. Thus, the main program will resume in the CPU where it was interrupted, regardless of the changes which have occurred during the interrupt handler routine execution.
For convenience of description, each of the eight interrupt lines 28 will be referred to hereinafter by the name of the interrupt signal (IRQ0 through IRQ7) on the respective line. As described in the above cited IBM Technical Reference Manual, in the IBM Personal Computer, two of the eight interrupt lines going into the Intel 8259A Programmable Controller 22 are are dedicated to the system timer and to the keyboard. The highest priority interrupt line IRQ0 is connected to the system timer and the next highest interrupt line IRQl is connected to the keyboard controller. This leaves the six remaining interrupt lines IRQ2 through IRQ7 to be shared among the I/O devices. The next highest interrupt request line IRQ2 is connected to the display adapter to indicate when the vertical retrace interval occurs. The second lowest priority interrupt request line IRQ6 is connected to the diskette controller and is active when that controller has completed an operation. Thus it is seen that the availability of spare interrupt lines 28 to the programmable interrupt controller 22 will be further diminished by the addition of optional I/O devices such as serial communications adapters, parallel printer adapters, fixed disk controllers, local area network adapters, and the like.
An approach to solving the problem of a limited number of interrupt lines is provided by the logic circuit arrangement described in the copending patent application by David Bradley, entitled "Interrupt Level Sharing," U.S. patent application Ser. No. 629,868, filed July 11, 1984 now Pat. No. 4,631,670 and assigned to the International Business Machines Corporation. In the prior art, I/O devices which attach to an interrupt line, operate by holding the interrupt line (IRQ) at a low level and then drive the line high to cause an interrupt signal. In contrast, the Bradley patent application provides a shared interrupt logic unit on each of a plurality of I/O devices sharing a single interrupt line. The shared interrupt logic unit allows the shared interrupt line to float to a high potential. Each I/O device sharing the interrupt line may cause an interrupt signal by pulsing the shared interrupt line to a low potential level, using its respective shared interrupt logic unit. The leading edge of the pulse arms the programmable interrupt controller and the trailing edge of the pulse signals the programmable interrupt controller to cause the interrupt request to the CPU. The shared interrupt logic unit on each I/O device must monitor the shared interrupt line for the occurrence of an interrupt signal from one of the I/O devices connected to the line. When any I/O device connected to the interrupt line drives the line to a low potential, the shared interrupt logic unit on each respective I/O device connected to the line, will prevent the issuing of any further interrupt signals until all of the shared interrupt logic units are rearmed by a global rearm signal. The shared interrupt logic unit on each respective I/O device connected to the shared interrupt line, includes an interrupt status bit and an interrupt enable bit which can be controlled and monitored by its corresponding interrupt handler routine. If the interrupt status bit for an I/O device is at a first binary state when the shared interrupt logic unit is rearmed, the shared interrupt logic unit reissues an interrupt signal. In this manner, the loss of interrupts is prevented if two I/O devices issue an interrupt signal at the same time and an interrupt handler routine issues a global rearm signal after servicing one of the I/O devices.
The problem of how to share a single interrupt line among several I/O devices serviced by several different interrupt handlers, becomes complex in multiprogramming or multitasking systems. In a multitasking system, programs can be started or terminated at any time and in any order. If a procedure were to be adopted of sequentially saving the contents of the interrupt vector for sequentially loaded interrupt handlers, such a procedure will not work in a multitasking system where any one of a sequence of programs sharing the same interrupt can be terminated in any order.
Multitasking operating systems have the ability to switch between several applications programs which are concurrently resident in the system RAM. Typically, a multitasking operating system will partition the system RAM into a plurality of protected regions, each of which will contain a separate applications program. Each partition can have its own command prompt and thus the user can switch to a background partition, start a compiler, print a listing, or start any other program requiring little keyboard interaction, and then switch back to the main (foreground) partition and continue to work while the other programs are running. For example, in the IBM Personal Computer, a multitasking operating system can work by installing itself between the DOS operating system and the applications programs. Whenever an applications program calls up DOS or the basic I/O system, the applications program must first go through the multitasking operating system. The multitasking operating system can then decide whether it's time to run one of the other concurrently active applications programs and it can give control of the system to the new applications program instead of continuing the original applications program which made the call to DOS. For those applications programs which do not make frequent calls to DOS, a time slicing technique can be employed to assure that the program in the multitasking environment will get its fair share of time at sufficiently regular intervals. In time slicing, the multitasking operating system keeps track of how long the currently running task has been executing. If a task does not make a call to DOS after a certain amount of time has elapsed, the multitasking operating system stops the currently running task and allows other applications programs to run for an equal length of time. Priority scheduling features can also be included in such multitasking operating systems to enable higher priority applications programs to obtain a greater proportion of running time.
It is in such multitasking operating systems that the problem of how to share one interrupt line among several I/O devices becomes acute. The out-of-sequence termination of the interrupt handlers for the I/O devices prevents the application of a simple concatenation procedure for the consecutive accessing of interrupt vector addresses, as a solution to the problem.